1. Technical Field
The invention relates to a bridge for coupling a client to a server computer and to a corresponding method, computer system and a computer program.
2. Related Art
From Statutory Invention Registration U.S. H1,895 an application provider and method for communication is provided for communication of an application provider between a first sub-system and a second sub-system of a common node.
For example, the application provider may be a mobile application provider, the first and second sub-systems may be a home location register and a visitor location register, and the common node may be a wireless telecommunication system. The system is implemented by means of an object request broker (ORB) such as the common request broker architecture (CORBA) defined by the object management group (OMG). A resource manager application serves as a “bridge” or “conduit” between a call processor and a resource assembly.
From U.S. Pat. No. 6,094,688 a system is known for modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources. This system provides interoperability between applications including a plurality of connectors for communicating with a like lurality of applications and an interchange server.
The interchange server includes an application collaboration module and service module. The services module transfers messages between connectors and the application collaboration module. The application collaboration defines the interoperability between two or more applications. The interchange server service module includes a transaction service and an error service. Transactions are executed in the application collaboration module.
From U.S. Pat. No. 6,085,220 an enterprise interaction hub for managing an enterprise web system is known. The enterprise interaction hub includes a number of layers that interact to manage an enterprise web system.
An interaction layer receives requests to the enterprise web system and returns responsive web pages. A presentation layer is coupled to the interaction layer and generates the responsive web pages. A business layer is coupled to the presentation layer and provides business logic for use by the presentation layer in generating the responsive web pages.
An integration layer is coupled to the business layer and interfaces with existing legacy data to provide the legacy data to the business layer. A trend collection layer monitors and accumulates historical information from the interaction layer, the presentation layer, the business layer and the integration layer. The trend collection layer also stores the historical information in a trend database.
A profile database, accessible by the presentation layer and the business layer, stores profile data, including data mined from the trend database, that characterizes individual user access to the enterprise web system. The profile data is used by the presentation layer and the business layer to provide customized dynamic content in the generated web pages.
From U.S. Pat. No. 6,085,030 a network component server is known. The component server architecture enables consumer nodes of a computer network to interact with heterogeneous software components and services distributed throughout the network, as well as network devices and data.
Distributed interactions between a consumer and a heterogeneous software is achieved, in part, by registering and locating the component and services. An object neutral global component registry with access controls of the architecture interoperates with the component management service to transparently ensure proper administration, of indication and run-time binding access to components offered in response to requests from applications executing on the consumer nodes.
The architecture is implemented on a component server node of the network that is configured to communicate with the consumer, i.e., client, nodes in client-server computing arrangements. That is, the component registry of the component server node responds to a consumer application request by locating a heterogeneous component for the consumer. The registry offers this component to the consumer by providing an appropriate interface between the object module of the software component. This registry is organized as a plurality of cooperating storage entities including a description repository, an offer repository, an interface adapter repository and an object factory repository.
A component server architecture is provided to interact with heterogeneous software components and services distributed throughout the network, as well as with network devices and data. Distributed interaction between a consumer and heterogeneous software is achieved, in part, by registering and locating the components and services.
An object-neutral global component registry with access controls of the architecture interoperates with a component management service (CMS) to transparently ensure proper administration, authentication and run-time binding access to components offered in response to requests from applications executing on the consumer nodes. The architecture is implemented on a component server node of the network that is configured to communicate with the consumer, i.e., client, nodes in client-server computing arrangements. That is, the component registry of the component server node responds to a consumer application request by locating a heterogeneous component for the consumer. The registry offers this component to the consumer by providing an appropriate interface between the object module of the consumer and the object module of the software component.
This registry is preferably organized as a plurality of cooperating storage entities including a description repository, an offer repository, an interface adapter repository and an object factory repository.
From U.S. Pat. No. 5,913,061 a modular application collaborator is known for providing inter-operability between applications including a plurality of connectors for communicating with a like plurality of applications and an interchange server. The interchange server includes an application collaboration module and a service module.
The service module transfers messages between connectors and the application collaboration module. The application collaboration module defines the inter-operability between two or more applications and includes a trigger and a transaction responsive to the trigger. The trigger is activated upon receipt of data from one or more connectors resulting in the transaction delivering data to one or more connectors for transfer to an associated application.
From U.S. Pat. No. 6,115,646 a dynamic and generic process automation system is known. This includes a generic object-oriented process automation engine that provides workflow management services in a heterogeneous distributed computing environment. The system consists of three major parts: a build time part used to capture and store process definitions, and to request the enactment of a process; a run time part used to schedule, execute, and monitor the requested process; a CORBA to plug-in-software applications needed to execute processes and to allow interactions among the system components. This system is event-driven and provides scheduling and resource allocations schemes.
The system can incorporate a trader service which provides a “yellow pages” for objects; it allows objects to publicize their services and allow clients to find them based on upon which services the client needs. For example, a resource allocator can use the service to find a resource that satisfies a set of agents constrains.
The above referenced prior art systems and methods mostly rely on object oriented software technologies, such as CORBA. CORBA is a vendor-independent architecture and infrastructure that computer applications use to work together over networks. In CORBA, every object instance has its own unique object reference, an identifying electronic token.
Clients use the object references to direct their invocations, identifying to the object request broker the exact instance they want to invoke. The client acts as if its invoking an operation on the object instance, but it is actually invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation continues through the object request broker, and the skeleton on the implementation side, to get to the object where it is executed on the server.
The object request broker provides a mechanism for transparently communicating client requests to target object implementations. The object request broker simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the object request broker is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object and returning any response to the caller.
The IDL stubs and skeletons serve as the “glue” between the client and the server applications, respectively, and the object request broker. The transformation between IDL definitions and the target programming language is automated by a IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
Another important object oriented technology is Enterprise Java Beans. Enterprise Java Beans provides a framework for components that can be “plugged in” to a server, thereby extending that service functionality. Client programs execute methods on remote Enterprise Java Beans by way of an Enterprise Java Beans object. The Enterprise Java Beans object implements the “remote interface” of the EJB component on the server.
A common disadvantage of the CORBA and Enterprise Java Beans object technologies is that corresponding applications being available in an company's intranet are not accessible through a firewall from the internet.
For this and other reasons companies recently have started to use the Simple Object Access Protocol (SOAP) as the object oriented technology of choice as (SOAP) is firewall compatible. SOAP is a protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of applications—defined data types, and a convention for representing remote procedure calls and responses. SOAP can be used in combination within an HTTP extension framework.
FIG. 1 shows an example of a prior art network. The network includes internet 1 and intranet 2 which are separated by firewall 3. A SOAP client 4 is coupled to SOAP server 5 via internet 1.
Within the companies' intranet 2 a CORBA client 6 and an EJB client 7 are coupled to a CORBA server 8 and an EJB server 9, respectively.
Because of the tight coupling between the CORBA and EJB clients 6, 7 and their respective servers 8, 9 the applications of servers 8 and 9 are not accessible through the firewall 3 from the internet 1. As a consequence the SOAP client 4 can only access the SOAP server 5—or other servers which are not shown in FIG. 1—over the internet 1 but can not access applications provided on servers 8 or 9 in the company intranet 2. This is a serious disadvantage for offering a variety of applications to customers, in particular if existing CORBA and EJB systems are available.